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Abstract. The generic trace format GenTra4CP has been defined in 
2004 with the goal of becoming a standard trace format for the obser- 
vation of constraint solvers over finite domains. It has not been used 
since. This paper defines the concept of generic trace formally, based on 
simple transformations of traces. It then analyzes, and occasionally cor- 
rects, shortcomings of the proposed initial format and shows the interest 
that a generic tracer may bring to develop portable applications or to 
standardization efforts, in particular in the field of constraints. 
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1 Introduction 

Following the RNTL OADymPPaC project [9], a generic trace format, called 
GcnTra4CP (Generic Trace for CP), has been proposed in 2004 in order to spec- 
ify traces of CSP(FD) resolution. One of the objective was to allow the develop- 
ment of portable powerful tools for solvers analysis. This format was designed 
as a kind of standard, consisting of a precise syntax of trace events including an 
XML DTD, and an operational semantics, called observational semantics, which 
is a partial operational semantics applicable to a set of finite domains solvers. 

Such "standard" conforming tracers were implemented in four solvers. Sev- 
eral tools for analysis of resolution and search strategies were developed in four 
different environments, just using the generic trace GenTra4CP. They have been 
used with success after a minimal customization work for each of them. How- 
ever, at that time, no formal characterization of the generic nature of the trace 
format has been given. Even if the implementation of the tools starting from a 
well defined generic trace could be realized without difficulty and even if there 
was obtained a considerable gain in portability, it was virtually impossible to 
assess in advance the effort of adaptation needed for a solver to use the tools. 
Moreover it was not always possible to figure out exactly what some tool was ac- 
tually observing. GenTra4CP format has been used only in the project in which 
it has been defined. 
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This paper attempts to overcome these limits, by defining formally the con- 
cept of generic trace. It analyzes formally the nature of the generic format Gen- 
Tra4CP and its limitations that could have made difficult its broader use. It also 
shows the interest that a generic tracer approach may bring for standardization 
efforts and portability of applications, in particular for constraints, in proposing 
an approach of trace based semantics grounded on a partial operational seman- 
tics. 

After an introductory section on operational semantics of traces, the Section 3 
introduces some simple relations between traces in order to formalize the concept 
of generic trace, and to provide a proof method of compliance of a particular 
process trace with the generic one. The Section 4 explains the generic approach 
and its interest for portability. The Section 5 applies this approach to the case 
of GenTra4CP verifying the compliance of a particular solver. The formal de- 
scription of the GenTra4CP trace format is borrowed from [9] and from [6] for 
the solver. This allows a better understanding of the strengths and limitations 
of this approach as introduced in 2004. We can then establish a possible link 
between the efforts of constraints standardization, and the specification method 
based on generic trace. 

2 Preliminaries 

A trace object consists of an initial state sq followed by an ordered finite or 
infinite sequence of trace events, denoted < sq, e >. T is a set of traces. A 'prefix 
(finite, of size t) of a trace T = < So, e^" > (finite or infinite, here of size n > t) 
is a partial trace U t =< sq, ei > which corresponds to the t first events of T, with 
an initial state at the beginning. A prefix consisting of just an initial state is of 
size 0. The set of all the prefixes of T is denoted Pref(T), with T Q Pref(T). 

Every trace can be decomposed into segments containing trace events only, 
except prefixes which start with a state. An associative operator of concatenation 
may be used to denote sequences concatenations. The neutral element is e (empty 
sequence). A trace may describe state transitions, such that a segment may also 
be represented as sT t St where s is the state in which the sequence T t starts and 
St the state reached after the last trace event in the sequence. A segment (or 
prefix) of size is either an empty sequence or a state. 

A domain of traces over T, T>Tt-, is a se t whose elements are sets of all 
prefixes of one or more traces of T ■ An element is prefix closed. Such a set is 
closed by union and intersection, and, two included elements are such that the 
smaller contains all the prefixes of some traces of the largest. A trace domain 
is a complete lattice denoted T>Tr{Q, -L, T, U, (~l) where _L is the empty set and 
T = Pref(T). 

Traces are used to represent the evolution of systems by describing the evo- 
lution of their state. We will distinguish two kinds of traces: 

— the virtual traces (7~ v ) whose events have the form e = (r,s) where r is a 
type of action associated with a state transition and s, called virtual state, 
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the new state reached by the transition and described by a set of parameters. 
Virtual trace corresponds to sequences of states of an observed system. 

— the actual traces (l~ w ) whose events have the form e = (a) where a is an 
actual state described by a set of attributes. Actual traces corresponds to 
sequences of events produced by a tracer of an observed system. Thy usually 
encode states changes in a synthetic manner. 

We give here a simplified but sufficient definition of observational semantics. 
More general definitions can be found in [2] . 

Definition 1 (Observational Semantics). 

An observational semantics consists of < S, R, A,T, E, I , Sq >, where 

— S: domain of virtual states, 

— R: finite set of action types, set of identifiers labeling the transitions. 

— A: domain of actual states, 

— T: state transition function T : R x S — > S , denoted T(r, s) = s' or T(r, s, s') 
if it is a relation, 

— Ei : local trace extraction function Ei : S x R x S — !> A, 

— Ii : local trace reconstruction function : S x A —> R x S , 

— So C S, set of initial states. 

The extraction and reconstruction functions can be extended into functions 
E (resp. /) between sets of virtual and actual traces, and must verify the relation 
of faithfulness, I = E . Local and extended functions satisfy the properties: 

E(s a ei...e t ...) = s E l (s ,r ll si)...E l (s l _i,r. l ,s l )... with Ei(si-i,ri, Si) = a t , 
and 

I(s ai...ai...) = s Ii(s , al)...Ii(si, Of+i)... with J;(si_i,a;) = (r^s,-). 

The local and transition functions may be represented by rules as illustrated 
by the Figure 1. 

The observational semantics of an observed process can be considered as 
an abstraction of some refined operational semantics [1]. This relation will be 
expressed here as a relation between domains of traces. Such a relation may 
be expressed either between virtual or actual traces. Due to the faithfulness 
property, the abstraction function D w on actual traces verifies with D„, the 
abstraction function on virtual traces, the following relations: D v = E c o D w o I d 
and D w = I c o D v o Ed- 

In the following it will be assumed that the faithfulness property is satis- 
fied, whatever is the abstraction level of the trace description. In this case, the 
extraction function is deducible from the reconstruction one and reciprocally. 
Therefore it is sufficient to specify the transition function with the extraction 
only or with the reconstruction. In practice, only actual traces are manipulated 
by the users, but thanks to the faithfulness property, for validation purposes, 
the virtual trace may be used. 
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reduce 



reduce 




[reduce, c, v, (S' e - S e ), (2?(u) - ©'(«)), a] 
[reduce, c, w, a, A%, a] 



reduce 



<V(v), S e , A > -> < V(v) - A°, S e Ua, A-(c,a)> 



{} 



Fig. 1. Example of description of reduce in the OS of GenTra4CP (Section 5) with 
transition rule, extraction and reconstruction. Computations are specified on the right 
side 

3 Abstraction relations: subtraces and derivations 

We introduce simple transformations on traces: subtraces and derivations. As it 
is sufficient to describe transformations on the virtual traces, they are described 
using one part of their description, namely < S, R, T, So > only. 
Subtraces are obtained by considering a subset of parameters. 

Definition 2 (Subtrace). 

Given a set of virtual traces T defined by < S, R, T, Sq >, if S' C S is defined 
on a subset of parameters which do not depend 1 on any other parameter ofS—S', 
R' C R is a subset of action types which use or modify these parameters only 
such that no other action type of R— R' modifies them, S' is the restriction of Sq 
to S' , and T' the restriction of T to S' and R' , then the set of traces T' defined 
by < S',R',T',S' > is a (parametric) subtrace of T , denoted Subp{T,T'). 

Note: it is possible that 5" C S and R' = R (S — S' contains redundant parame- 
ters, i.e. which depend only on the other parameters and thus may be removed). 

Definition 3. (Derivation field and derived trace) 

Given two sets of traces T c and Td, where T c and Td are said respectively 
concrete and derived, Id is a derivation field of7~ c by D if there exists a mapping 
D : Pref(7~ c ) — > Pref(7~d), called a derivation, such that for all finite derived 
prefixes td of size n and for all concrete prefix t c such that D(t c ) = td, there exists 
an increasing chain of concrete prefixes [t^t 1 , , ■•■i^c~ 1 i^c] (not necessarily 
contiguous), such that 



— Vi > if D(t l c ) = t d with t d prefix of td made of the i first events, then 



If D is surjective, the setTd is called derived trace by D ofT c , noted DrvD(T c ,Td)- 



A parameter p depends on p' iffp' is used in the computation of p in some transition. 



D(t° c ) G S , d , 
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As defined, D is a partial function. It can be made total by considering that 
all elements of So, c have an image in So.d and that the image of each prefix 
between t\ and t l c +1 is D(i'). 



s d 



t d 



t'_d 

->- s_d ■ s'_d 



t_c 



t'_c 



Fig. 2. Derivation (dashed arrow correspond to the totalized derivation), t x denotes a 
prefix 



This approach puts emphasis on traces without considering the way they 
have been produced or the way they are specified. The main idea is that a trace 
transformation is the result of a computation on likely full prefixes of concrete 
traces, represented by de derivation D. 

Property 1. 

Given two derivations ~D\ and D 2 , if D\ is surjective or if D 2 is total, D\ oD 2 
is a derivation. 

A parametric subtrace (definition 2) is a derived trace. 

The following establishes a method of proof that two sets of traces specified 
by transition relations are related by a derivation. 

Definition 4. (Simulable Trace) 

Given two sets of traces T c (concrete) and Td (derived), respectively defined 
with < S c , R c , T c , Sq. c > and < Sd, Rd, Td, So,d >, % is simulable in Td if R c and 
Rd are in a one-one mapping h, and if there exists an application d : S c — >• Sd 
such that: 

- Vs G S , c ,d(s ) G S ,d- 

- Vr c G R c ,s c ,s' c G S c , T c (se,r c ,s' c ) => 3s d ,s' d e Sd,d(s c ) = s d A d(s' c ) = 
s'd^Td(sd,h(r c ),s' d ). 

Theorem 1. 

Given two sets of traces T c (concrete) and Td (derived), such that T c is simu- 
lable in Td, then Td is a derivation field for T c and the corresponding derivation 
is total. 

Corollary 1. 

Given two sets of traces T and T' such that there exists a parametric subtrace 
of 7~ simulable in T' , then T' is a derivation field for T ■ 
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4 Generic Trace 

The idea of generic trace meets the needs of specification and portability. It is 
intended to specify a process or an algorithm by its observable behavior, i.e. 
the trace of abstracted operations that it is expected to implement. The level of 
description must be general enough to include family of processes, and the level 
of granularity must be sufficiently refined to be used by a family of applications. 
This may be the case for example for applications such as monitoring, debugging, 
visualization tools, or any application using the generic trace. 

Definition 5 (Generic Trace (GT)). 

Given a family of processes p € P. each of them equipped to produce traces 
T p , a set of traces T g is generic if for each process p in the family, there exists 
a derivation D p of its traces which is a parametric subtrace ofT g , that is: 

Vp G P, 3 T such that Drvri p (T p ,T) A Subp(T g ,T). 

Three questions are then worth posing: 

— How to ensure that the trace produced by some process is compliant with 
the GT? 

— Can the GT be used in application development, with the guarantee that 
the application will work with any compliant process? 

— Can the GT be extended to handle more processes in such a way that existing 
applications will still work? 

Here are some possible answers. 
Compliance to the Generic Trace 

A trace of a process is compliant w.r.t. the GT if it satisfies the definition 5, 
i.e. there exists a subtrace of the GT which is a derivation of a subtrace of those 
of the process. It is thus possible either to implement straightforwardly the GT 
as it is (in this case the process produces exactly the GT), or to prove that the 
traces a process p may generate verifies 37"', DrvD p (T p , T') A Sub p (T g ,T')- 

Building tools with the Generic Trace 

The interest of a generic trace is that it facilitates the development of tools 
that can be used with all compliant processes. The development is made consid- 
ering that the tool uses at least a sub-GT covering sufficiently many processes. 
Thus it is possible to adapt the tool to the process p by applying to the trace 
generated by the process (without any modification) the derivation D p to get a 
GT. This can be done at le level of the process (process can use any tool) or at 
the level of the tool (tool can be run with this particular process) . The Figure 3 
illustrates these two ways to adapt processes with compliant tracer and tools. 

The fact that the GT has a formal specification makes it possible to realize 
a prototype (executable specification) which shall be itself a new compliant pro- 
cess. It is thus possible to use such a prototype to develop and test tools. This 
development method guarantees that any tool made on the top of the GT will 
be able to work with any compliant processes. 
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Process p 

1 




Fig. 3. Use of a Generic Trace: process or application adaptation 
Generic Trace extensions 

As long as an extension of the GT preserves the fact that a process is com- 
pliant w.r.t. a subtrace of the extended GT, they still are compliant w.r.t. the 
extended GT. It is sufficient to ensure that any GT extension preserves the para- 
metric subtraces. This guarantees that the compliant processes will continue to 
be usable by tools using the original GT. 

5 The Generic Trace GenTra4CP 

In the final document [9] , the generic trace GenTra4CP is defined with an obser- 
vations semantics whose transition function is defined with a subset of parame- 
ters. Thus only a generic subtrace has a formal semantics. The other parameters 
arc described informally by the description of other attributes of the actual trace. 
Their syntax is fixed by a DTD XML and informal explanations arc provided 
for each new attribute. We recall here the semantics as originally presented in 
[9] (section 3.3. 1) 2 

Beginning of Citation: 

Definition 6. (Solver State) 

A solver state is a 8-tuple: S = (V, C, T>, A, E, R, S c , S e ) 
where: V is the set of declared variables; C is the set of declared constraints; 
T> is the function that assigns to each variable in V its domain (a set of values 
in the finite set D); A is the set of active pairs of the form (constraint, solver 
event 3 ); E is the set of solved constraints; R is the set of unsatisfiable (or 
rejected) constraints. S c is the set of sleeping constraints; S e is the set of solver 
events to propagate ("sleeping events"). 

2 Here one uses n instead of v to denote the current node of the choice-tree. 

3 This work inherits from two areas, constraint solving and debugging, which both use 
the word "event" in correlated but different meanings: a solver event is produced 
by the solver and has to be propagated (e.g. the update of the domain bounds of a 
variable); a trace event corresponds to an execution step which is worth reporting 
about. 
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Control 



new variable 
new constraint 
post, remove 
restore 
choice point 
back to 

solution, failure 



v, 

c 

c 

v, 

n 

n, 

n 



D v , 



A v 



reduce 

suspend, 

solved 

reject 

awake 

schedule 



Propagation 

c, v, a, 
A c v , a 

c 



c, 
c, 
c, 



Table 1. Attributes of the actual trace of GenTra4CP 



A, S Cl E and R are used to describe four specific states of a constraint during 
the propagation stage: active, sleeping, solved or rejected. 

The store of constraints is the set of all constraints taken into account. The 
store is called a in the following and defined as the partition a = {c | 3(c, a) G 
A} U S c U E U R. All the constraints in a are defined, thus a C C. The set 
of variables involved in the constraint c is denoted by var(c). The predicate 
false(c,T>) (rcsp. solved(c,T>)) holds when the constraint c is considered as 
unsatisfiablc (rcsp. solved: it is universally true and does not influence further 
reductions any more) by the domains in T>. 

The search is often described as the construction of a search-tree. 

Definition 7. (Search-Tree State) 

The search-tree is formalized by a set of ordered labeled nodes Af representing 
a tree, and a function £ which assigns to each node a solver state. The nodes in 
Af are ordered by the construction. Three kinds of nodes are defined and charac- 
terized by three predicates: failure leave (failed(S)), solution leave (solution(S) ) , 
and choice-point node (choice-point(S)). The last visited node is called current 
node and is denoted n. The usual notion of depth is associated to the search- 
tree: the depth is increased by one between a node and its children. The function 
8 assigns to a node n its depth 5 '(n). Therefore, the state of the search-tree is a 
quadruple: T = (Af, S, S, n). 

In the initial solver state, no denotes the root of the search-tree and all the sets 
that are part of S are empty. 
End of Citation 

The remaining description consists of the description of each event type of the 
actual trace (called in [6] "generic trace schema" ) by introducing other attributes 
(some of them are redundant like external and internal constraint identifier). One 
illustrates the methodology of GT construction by analyzing one "implementa- 
tion" of the GT as presented in [6] . In this paper three "specializations" of the 
GT are detailed for three solvers (GNU-Prolog, Choco and PaLM). They consist 
of a description of the operational semantics of each solver by their transition 
function. We show here that the proposed OS for PaLM [5] is compliant. Among 
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<V, V> (vgV 

new variable 



<VU[o}, T>U{(v,V v ,t)}> \T>(v)=D Vli 
<C> ( c&C, 



new constraint 



post 



< C U {c} > \ var(c) C V 
< A > / c G C, 



<AU{(c,l)}> \c^a 



X. .v. :: f ch-pt(S), 

Choice DOint —= ; — r — -r-. tttt; < J , , 

< S, > fn^f, n G jV 

back to 



< E{n), n> \ch-pt(§) 

<M, S, §> 
n}, ru{(u,S)}, n 

<A/~, S, §> / flr(S 



a', v. :; r S0 /(S), 

SO UtlOn —= -. — ; — t, zrr^ \ J Lr 



failure 



restore 



<Afl){n}, ru{(n,S)}, n> \n £ AT 

< a > 
remove — 

< a - {c} > 

< v(v) > ( v ev, 



{cea} 



< V(v) UA V > \A v n V(v) = 0, A v C 
Fig. 4. OS of GenTra4CP (control, without the parameter S) 



the three experimented solvers, PaLM has a clearly different semantics. The 
transition part of the OS is depicted in the figures 4 and 5. 

In order to show that the OS (trace semantics) of PaLM is compliant, one 
need the following properties of the GT: 

(Gl) ao/(S) => R = 

(G2) /Jr(S) R ± 

(G3) (ewiype = reduce) => R = 

(G4) (eufype = awake) => (i? = A A = 0) 

(G5) (evtype = schedule) =>- (R = A A = 0) 

One admits: 

(PI) dependence(c, a) <^ awcond{c,a) 

(P2) selected) => 3c G C action(c,a) 

(P3) 3w G var(()c),2?(w) = ^> false(c,V) 



Theorem 2. 

TTie GT" restricted to all events depicted in the Figures 4 ond 5 but back to and 
solved, is a parametric subtrace of GenTra^GP 7 derived from the trace specified 
for PaLM (Figures 6 and 7). 
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„ <P(«), S B , A> \ f M =f W - ^, supprime ^, 

reduce — — ^ (c, a) € A, v £ var(c), Red. gn. a, 

<©'(«), S4, A'> |^ = a _ (Cj0)j S ' e =S e Ua 

SUSpend <A-Ue,t)},%!u{c}> {(G ' a) G A} 

< A, E> f(c,a)eA, 
solved 



reject 



<A-{(c,o)}, EU{c}> [ solved(c, V) 
< A, _R > ((c,a)eA, 



<A-{(c,a)}, Ru{c}> \false{c,V) 



< A, S c > (c£Sc, a£S e U{±}, 

awake — 



< A U {(c, a)}, S c — {c} > \ awcond(c, a) 

■ I I < Sc, Se > f c 6 S c , e £ S, 
schedule 



< S' c , Si > \ action(c, a) 



Fig. 5. OS of GenTra4CP (propagation) 

newvariable, new constraint idem GenTra4CP 
post , choice point idem GenTra4CP 

< AT, S, § > f sol(S), 

solution 
failure 



<Afl){n}, Eu{(n,S)}, n> \n $ N 
< AT, S > {n4M, 



<Afu{n}, ru{(n,S)}, n> \Rj^ 
remove idem GenTra4CP 



restore — ^M±-Q±JL± _ { E = {£(v, d)\d e R v }, 



veV, R v C {de B\£(v,d) C\a / 0}, 
E = {£(«,d)|d€i^}, 
^ ' "* ' la actions de restauration de T>(v) 

Fig. 6. OS of PaLM [6] (control) 



6 Generic Trace and Constraints Specification 

This approach of semantics can be applied to constraints specification. The ques- 
tion then is whether it exists a generic trace covering all the constraints that one 
wishes to describe, i.e. covering different types of constraints (single, global, 
...), different domains ( FD, intervals, ...), different classes of solvers (CSP, SAT, 
rules, such as CHR), different levels (algorithms, modules, modeling) or different 
aspects (language, interaction, interfaces, ...) as well. 

We limit ourselves here to the CSP case. Each constraint has a declarative 
semantics defined by the relation it represents on its domains. The GT can thus 
provide a description of the possible effects of each constraint separately or in 
a network, regardless the particular algorithm it implements. In this sense such 
semantics is a kind of minimal description of what we should be able to observe 
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{uGvar(c), R = 0, A = {(c,a)}, 
AZ a 7^ set of inconsistent values for v, 
C C a explains the removal of A c v a from T>(v) 
The reduction generates a 

suspend — f' ^' ^ c r > . — {A = {(c, a)}} 
< 0, S c U {c} > 1 u ' yjJ 

reject - < A, R J* ^ - {A = {{c,a)}, v € var(c), ©(«) = } 
< S c , A > f A = 0, c G S c , i? : 

awa ke 



< Sc - {c}, {(c, a)} > (_ a € Qh U {-L}, dependence(c, a) 

schedule — < gi> — { se / ec t(a), A = 0, a £ Q t , R = 0S C / } 

< {a}, g t - {a} > 



Fig. 7. OS of PaLM [6] (propagation) 



of the behavior of a constraints set. It can be used to define any kind of interfaces, 
particularly for problem modeling. 

In practice, as is what has been done for GenTra4CP, one should start with 
a definition of an actual trace whose meaning can be given by a reconstruc- 
tion function. It should be completed by an OS as large as possible such that 
parameters relevant to potential interfaces and applications are fully described. 

We illustrate this approach of a generic semantics with a simple resolu- 
tion example, showing the two traces obtained with GNU-Prolog and PaLM 
for this example. Both solvers have been instrumented to produce the generic 
trace for CSP(FD), and their traces can be "understood" using the OS of the 
Figure 8. Both traces (Figure 9) correspond to the resolution of (GNU-Prolog 
syntax) fd_element_var( I, [2,5,7] , A) , (A#=I ; A#=2) which admits one so- 
lution only 4 . The declarative semantics of this constraint (all variables are finite 
domain) can be expressed as: f d_element_var (I , L, V) (L liste) constrains V 
to be equal to the Iith element of L. Thas is to say all triples such that i E I, 
u G L(i), d£V and u = v arc valid. The interval [a-6] denotes from a to b and 
[a, b] , a and b. One may observe 5 that the traces are different, so, in particular: 

— the domain of I is not the same for GNU ( [1-3] ) and for PaLM ( [0-2] ); 

— the order and the values of the values removal are not the same, as the choice 
of variables to consider; 

— search spaces are different; 

— a specific variable occurs in the trace of PaLM (v-1). 

4 PaLM produces shortcuts such that the sequence reduce suspend schedule awake is 
displayed as reduce awake. Such shortcut does not have any semantics in GenTra4CP 
(it could be adapted). This shows only that the PaLM OS given in [6] was not actually 
compliant to the GT. 

5 GenTra4CP produces traces in XML, readable but verbose. A more concise repre- 
sentation has been adopted here. 
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. [new variable, w, D„, 4 ] r 
newvariabe — r-^ — . , „ — — { V 

<V, V >^<VU{v}, VU{{v,D v ,i)} > 11 

[new constraint, cl r , 
new constraint ; ' , ^ r 

< C >^< C U {c} > u 

[post, cl ,, 
P ° St <AM<AU{(C,1)}> {} 

[choice point, 71] ,, 
cho.cepo.nt < ^ - §> ^ <Aru{n}) ru{(n ,§ )} , n> 

[reduce, c, u, a, /ij, a] „ 
re UCS <£>(t>), S e , 4 >^< V{v)- A%, S e Ua, A-(c,a)> " 

[suspend, c, a] r , 
SUSpe <A, S c >^<A-{(c,a)}, 5 c U{c}> 11 
[awake, c, a] 
3Wa 6 <A, S c >->< AU(M)), S c -{c}> 11 



Fig. 8. OS of GenTra4CP (reconstruction) 



These variations are irrelevant when comparing the respective semantics (re- 
naming, extra variable) and from both actual traces one may reconstruct the 
corresponding virtual ones. However some variations should be examined and 
fixed like the limit values of I, or some specific attributes. 



7 Discussion 



The semantics of traces presented here corresponds to the "Observable Seman- 
tics" of Lucas [8] or the partial trace semantics of Cousot [1]. The parameters of 
the virtual states are, as expressed by Lucas, "syntactic objects used to represent 
the conduct of operational mechanisms" . The traces are abstract representations 
of process semantics which allow to take into account the sole details we want to 
consider as common to a set of processes. The choice to relate two forms of trace 
(virtual and actual) corresponds to the need to reconcile different pragmatic ap- 
proaches: formal specification of semantics more or less abstract, and empirical 
manipulations of traces like in trace-based systems [10]. We established here a 
particular method to demonstrate compliance of a process trace with regards to 
a generic trace. This approach allows to establish formal relations with the trace 
theory [3] too. 

We have shown here that the definition of the trace GenTra4CP can be well 
defined in such a theoretical framework, and we have characterized by relatively 
simple transformations (parametric subtrace, similarity and derivation) the for- 
mal linkages between the observed processes and the generic trace. This analysis 
revealed some insufficiencies in the formal definition of GenTra4CP as the lack 
of formal verification of particular traces solver compliance. Simonis & al [11] 
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1 [0] choice point node(0) 
2[l]newVariable vl [0-mx] 
3[l]newVariable v2 [0-mx] 
4 [l]newConstraint cl 
f d.element ( [vl , [2 , 5 , 7] , v2] ) 
5[l]post cl 

6[l]reduce cl vl [0,4-mx] 
7[l]reduce cl v2 



3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
IS 
16 
17 
18 




1 
2 



'0] newVariable vO I [0-mx] 
'0] newVariable vl A [0-mx] 
'0] newConstraint cO 



elementCI, [2,5,7] ,A) 
'0]post cO 
'0] suspend cO 
'0] awake cO 

0] reduce cO vO [3-mx] max 
'0] reduce cO vl [0,1] min 
'0] reduce cO vl [8-mx] max 
'0] suspend cO 

'0] newConstraint cl eq(I,A) 

'0]post cl 

'0] suspend cl 

'0] awake cO Cv0,max) 

'0] reduce cO vl [2-7] empty 

01 reject cO empty 

'0] failure 

;o] newVariable v-1 I [0-1] 
'0] reduce c2 v-1 [0,1] empty 



[0-1, 3-4, 6, 8-mx] 
8 [1] suspend cl 
9 [1] choice point node(l) 
10 [2] newConstraint c4 



x_eq_y( [v2,vl] ) 
11 [2] post c4 
12[2]reduce c4 v2 [5,7] 
13 [2] reduce c4 vl [1,3] 
14 [2] suspend c4 
15 [2] schedule v2 dom 
16 [2] awake cl 
17[2]reject cl 
18 [2] failure node (2) 



Fig. 9. Partial actual trace of GNU-Prolog and PaLM with the given example. The 
second attribute is the choice-tree depth 



note that the generic trace GenTra4CP contains too many details with a too so- 
phisticated specification. This is certainly true if the objective is just to analyze 
the evolution of some problem variables and some aspects of the search. In this 
case the need of trace information is limited and it is less work to implement 
directly the capture of the needed information rather than implementing a full 
generic trace format. But it is different if the objective is to create a generic 
interface between solvers and many more applications. Our study shows also 
that GenTra4CP probably contains too many optional details with no clear se- 
mantics, such that implementers feel free not to implement many of them, or 
to implement them with just specific implementation dependent semantics. A 
more demanding approach, but which may be more useful, could be to specify 
formally more attributes of the generic trace. 

Moreover, as it has been observed in the Section 4, it is the task of the 
developer of a solver to implement a generic (sub)trace or to adapt the tools 
which have been developed on the basis of the generic trace. The investment to 
make is measured by the gap between the developed process trace and the generic 
trace (formally a derivation, Figure 3). It may seem easier to implement an ad- 
hoc trace systematically, rather than to implement once a compliant tracer, or 
to adapt a tool each time needed. Langevinc and Ducassc have shown [7] that a 
generic approach could have more advantages than drawbacks, but it is similar 
to a standardization effort. 

Such an effort can only result from the action of a large community, and not 
from a small group as in the case of GenTra4CP. The project of standard [4] 
focuses mainly on the definition of a Java interface that includes in particular the 
major types of variables, unary constraints, some binary and global constraints, 
as some strategies to search for solutions. But the question of the semantics 
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cannot be ignored. If the declarative semantics of simple constraints poses little 
problem of specification, it is not the same for the operational semantics, whose 
accuracy depends on potential applications developed with constraint problems. 
The approach presented here, based on a generic trace semantics, may be a 
way since it provides a framework for specifying outcomes and side effects of 
constraint, revealing for example constraints interactions independently from 
specific implementations. 

8 Conclusion 

GcnTra4CP has been an innovative approach using a partial trace semantics to 
handle both problems of specifying constraint solvers (on finite domains) and of 
portable analysis tools. Such an effort was similar to a standardization effort, 
but with no effective dissemination because of its limits (small group who made 
it, some technical gaps and restricted to one constraints domain). 

We have introduced a simple formal framework based on trace theory and 
abstract interpretation to explain the method of generic trace construction, and 
to show the potential value of this approach to specify a partial semantics of 
constraints resolution. 

The realization of a generic trace for a significant set of simple or global con- 
straints certainly represents a considerable amount of efforts. It seems however 
that such an approach could not only allow the portability of potential applica- 
tions, but also contribute to the semantics of knowledge representation systems 
which combine several methods like constraints and rules. 
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ANNEX: Proofs 

8.1 Proof of theorem 2 

One shows that a parametric subtrace of PaLM is simulable by a parametric 
subtrace of GenTra4CP. 

One considers the GT GenTra4CP, restricted to all the events of the Fig- 
ures 4 and 5 but back to and solved. Ignoring back to does not affect the search- 
tree construction but only its visiting strategy, and ignoring solved corresponds 
to removing the parameter E in the solver state. Furthermore the parameter 
corresponding to the explanations can be ignored, as it is not formalized in the 
OS of GcnTra4CP. 

According to the definition 2, the restriction to the subset of considered 
events is a parametric subtrace of GenTra4CP. 

The subtrace of PaLM to be considered consists just in ignoring the expla- 
nations. This does not restrict the set of action types (definition 2). 

In GenTra4CP and the considered subtrace, the control part T g uses ac- 
tually 4 parameters: Af, S, 5, v, and the propagation part S fl 8 parameters: 
V, C, T>, A, E, R, S c , S e , in total 12 parameters. 

In PaLM, the control part T p uses 5 parameters: Af, S, S, v, Qt, and the 
propagation part § p 9 parameters: V,C,T>, A,R, S c ,Qh,Qt,£', in total 13 pa- 
rameters (Qt is common). There arc some differences: 

— E, the subset of the "constraint store" , containing the valid constraints, is 
irrelevant in PaLM, as no satisfiability test is realized in PaLM (no "entail- 
ment" ) . 

— The set S e of the current events in PaLM is a queue (S e = Qh U Qt) whose 
head Qh (a singleton) contains the selected current event. 

— The state of the PaLM solver contains an additional parameter £ , the expla- 
nation function which serves to store the what is called the "explanations" . 
E is a partial function: £ : V x D — > T~'( (J ) 6 which assigns to each value 
removal (v, d) (v 6 V,d G T> (v)) a set of non relaxed constraints which ex- 
plains this removal. This partial function is updated by the events reduce and 
restore. 

— A, in PaLM, has at most one element. 

Thus one shows that the PaLM subtrace is simulable in the subtrace "PaLM" 
of GcnTra4CP. 

One uses the theorem 1. One defines the application d between the modified 
states T p x § p and T g x§ 9 , that is: (one omits S which is dcducible directly from 
AO 

Af, S, v, V, C, V, A, R, S c , Q h , Q t and 
M,S,v,V,C,V,A,R,S c ,S e 



6 V(cy): powerset of the store a (instance of the constraints which are in A, S c and R 
for PaLM). 
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as follows: identity for the 9 first parameters of PaLM Af, S, is,V,C, T>, A, R, S c , 
then Q h UQ t = S e . 

The action types have the same names ans their set is restricted to those in 
the Figures 6 and 7. 

The initial states To iP x So lP and Tn, g X So, g to be considered are: 
{rc p }, (rc p , §o, p ), rc pi p , p , p , p , P , p , p , P and 
{rc g }, (rc g , So,), rc g , g , g , g , g , g , g , g , g 

new variable, new constraint, post, choice point and remove are in correspondence 
as the transition rules are the same, as their modified parameters as well. 

For solution and failure, it is the same provided the properties (Gl) and (G2) 
hold. 

The case of restore is more complex. But, if one ignores the explanations and 
take for A v , R v (A v = R v ) for the same variable v, the conditions associated to 
the event of Gentra4CP are deducible from the explanations properties (restitu- 
tion of the removed values, then inexistent in the current domain of v). But one 
has to justify the update of S e in the transition rule of GenTra4CP. 

reduce. To A c v a it corresponds A% (set of inconsistent values) of the GT. 
By (G3) the properties R = correspond. Finally as d(Qh U Qt) = S e , then 
d(Q h UQ t Uo) = S e Ua. 

suspend. In the corresponding initial states (c, a) S A, and A' = A — {(c, a)} 
in the final states. 

reject. Uses (P3) for the initial states, and the final states are in correspon- 
dance. 

awake. Uses (PI) and (G4). 

schedule. Uses (P2) and (G5). S c and S e are invariants in the GT. 



